…nchiaki_merge

…mmit) to initialize_rates.c

This patch converts nearly all usages of the ``logical`` type to the
newly defined ``MASK_TYPE`` in the Fortran source files throughout
Grackle.
- The ``MASK_TYPE`` type is a custom datatype that just wraps a 32bit
  integer.

  - Because Fortran will not implicitly cast between logicals and
    integers we need to explicitly compare this value against
    ``MASK_TRUE`` and ``MASK_FALSE``.
  - For consistency with C semantics, if-statements that want to see
    if the mask is true always compare ``MASK_TYPE`` value is not equal
    to ``MASK_FALSE``.

- The **only** ``logical`` variable that wasn't changed was the
  ``end_int`` variable that we pass into ``interpolate_3Dz_g``.
  We haven't touched this variable to avoid interfering with existing
  efforts to transcribe that function to C/C++

- This patch is extremely similar in spirit to GH PR
  grackle-project#227. But there a fewer minor distinctions:

  - I am actually more confident in the correctness of this patch (I used
    custom tools to automate the majority of these changes)
  - I converted more variables in this patch (that other PR **only**
    changed the ``itmask`` variable).

I have explicitly confirmed that all tests continue to pass after the
introduction of this PR

The `cool1d_multi_g` subroutine expects an argument `iter`. Previously,
the `cool_multi_time_g` subroutine would pass a value of 1 directly to
this argument.

To simplify the process of transcription, we now store the value inside
of a local variable called `dummy_iter_arg` (if we didn't do this, we
would need to insert logic into our transcription routine to inject
a custom variable to hold the value of 1 and then pass a pointer to that
value into `cool1d_multi_g`).

The `cool1d_multi_g` subroutine expects an argument `iter`. Previously,
the `cool_multi_time_g` subroutine would pass a value of 1 directly to
this argument.

To simplify the process of transcription, we now store the value inside
of a local variable called `dummy_iter_arg` (if we didn't do this, we
would need to insert logic into our transcription routine to inject
a custom variable to hold the value of 1 and then pass a pointer to that
value into `cool1d_multi_g`).

I made some minor tweaks to where we pass in the pointers to the
i-dimension of grid_dimensions, grid_start, and grid_end. This is a
purely superficial change, but will allow automated transcription to
produce better code.

I made some minor tweaks to where we pass in the pointers to the
i-dimension of grid_dimensions, grid_start, and grid_end. This is a
purely superficial change, but will allow automated transcription to
produce better code.

A lot of the physical constants in the C and Fortran layers are defined
in slightly different ways. This commit seeks to make all of the Fortran
constants in one form or another in a way that won't produce
name-collisions with the existing constants defined in C.

The biggest difference for most constants is the precision of the
constant.

In the future, I would like to reduce the number of variants of
constants, but that will be easier after we finish the conversion.

Standardize parameter declaration

Gen2024 misc

Porting over various physical constants defined in the Fortran

…ate_newton_raphson_v2

Tests seem to be passed!

…(these are used internally by step_rate_newton_raphson)

…phson

… step_rate_newton_raphson.F

Previously, it was declared as a scalar.

I was tipped off to this issue by the fact that `cool1d_multi_g`
expected a 1D array. I further confirmed that `solve_rate_cool_g` was
passed the exact same array (by checking arg lists within
`calculate_cooling_time.c` and `solve_chemistry.c`).

Convert `logical` to `MASK_TYPE` (aka `integer*4`)

factor `step_rate_newton_raphson` out of `solve_rate_cool_g.F`

Gen2024 rank errors